Guideline: Equivalence Classes

The covering of equivalence classes is a powerful means of achieving a relatively high fault-detection rate with a limited set of test situations. The principle is simple and is applied by most experienced testers automatically and intuitively. These are called equivalence classes. Other terms used to refer to the design of test cases based on equivalence classes are “equivalence partitioning” and “domain testing”.

The following example is by way of clarification - In the decision of whether or not to issue a loan, many parameters play a role. One of those parameters is the age of the borrower. In the lending system, the age can vary between 0 and 100. As regards the age, the rules for granting or refusing the loan are as follows:

Younger than 18 => Refuse loan

From 18 to 55 => Issue standard loan

Older than 55 => Issue more expensive loan

Suppose that 3 test cases are being executed, with the following consecutive values for age: 16, 32 and 44. This is not a good choice, for several reasons:

There is no single test case in which a more expensive loan is issued. Any mistake in the issue of more expensive loans will therefore not be found.
If the system works correctly in respect of age = 32, then it is highly unlikely that a mistake will occur in respect of age = 44. The last test case is therefore superfluous.

In this example, for the parameter “Age” there are 3 equivalence classes, namely: 0 - 17, 18 - 55 and 56 - 100.

The various types of system behaviour in respect of this parameter are covered with 1 test case from each equivalence class.

The principle behind the application of equivalence classes is that each value taken from a class has the same chance of finding a fault and that testing with several values from the same class barely increases the chances of fault detection. It should be realised that this is an assumption. If, with a random value in an equivalence class the correct system behaviour occurs, it is in principle still possible for a fault to occur with another value. For example:

Fraudulent system behaviour - For example, if a programmer with fraudulent intent has added into the code:
”IF name = [my name] THEN discount = [ridiculously high]”
In principle, this cannot be found in any structured manner – only by sheer coincidence or by inspecting the source code itself.
Landing in the wrong equivalence class - In certain situations, system behaviour can occur that belongs to another equivalence class. This usually concerns boundary values that were assigned to the wrong equivalence class.

Even though the underlying principle is an assumption, it is a usable and useful one. By basing test cases on these equivalence classes instead of on every possible input value, the number of test cases is restricted, while a satisfactory coverage is obtained of the possible variations in the system behaviour.

Sometimes a distinction is made between valid and invalid equivalence classes: input values from the invalid equivalence class result in error messages. Input values from a valid equivalence class are processed as intended. This special form of coverage falls under the coverage of “Right paths / Fault paths”.

Equivalence classes are applicable to both input parameters and output parameters.